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INTRODI^TION 

Software portability, as defined by Pooie ani Waite 
[Ref. 1], is the measure of the ease wnish a prcgrar.! can b-:; 
transferred frora one environment to another; if ti.e eiforrt 
required to move the program is much less than that required 
to implement it initially, and the effort is small in an 
absolute sense, then that program is highly portable. 

Software portability has become an area of intense 
research as the "software crisis" continues to gain 
momentum. Ths less portable a program is, the more it will 
cost in terms of time and money to transfer it to another 
machine. One important impact of the lack of portability is 
that there will be little incentive to creato truly user 
friendly environments since the cost of producing suci. a 
system can not be amortized over many machine 
impie me n tat ions. 

There have been many attempts to solve the portability 
problem. >]any approaches have failed, some approdcr.es nnv*-' 
achieved limited success, few nave provide! a broadbaseJ 
methodology for achieving portability. High level languages 
were one of the first attempts at resolving the prol.lem. 
They, however, were either tco small to be useful, anl 
consequent ely extended, or too large and therefore subseted. 
Even if the language achieved a great deal of consistency 
over many implementation, programs were still desicnec witn 
non-standard, machine dependent features. 

Decompilers and language translators were It'velopel tut 
their complexity and poor reliability discoucajec! fuiLne; 
development 

The use of specifications to define the behavior cl a 
program is a method which offers a way to solve the 
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portability ^robien',. Aitbouc!x more worK is r(;:uiit.i to coda 
from a specif icatior , the description of pro^Lci?. reha'/iot 
can be more precise and implementation independence is 
possible. Compiicat ions arise/ however/ when the specifica- 
tion lanpuace is ambiguous. Formal specification lancuapes 
based on mathematical principles alleviate tnis proriem but 
often are more difficult to use and frequently larger than 
the programs they specify. Despite the difficulty in their 
use/ formal specif ications offer the greatest degree, of 
freedom from implementation without ambijuity. 

A specif ica t ion methodology based on initial algei>ras 
promises to be a viable answer to the portability proLlen 
without the drawbacks of most formal spe cl fi cat icn 
technigues. 

Algebras have a wide range of applicat ions. ilany 
researchers have proposed treating abstract data types as 
algebras [Eef. 2 ], [Ref. 3], [Ref. 4]. Algebras are partic- 
ularly vjell suited for describing data types; data types 
consist of data elements and operations on the data elemonts 
which is essentially the definition of an algebra. Farei, 
in his thesis [Ref. 5], noted that if algebras can re useJ 
to specify data typeS/ then the next step would be to use 
them to specify languages; a pregram is composed of instruc- 
tions which can be expressed using algebras. Furthermore/ 
research at the Naval Postgraduate School is aimed at usinq 
algebras to specify an abstract machine. A machine can be 
described using algebras since the execution of instructions 
causes the machine to change state. Algebras are used to 
define the effect each instruction has on the state of the 
machine . 

Put simply/ by using aigebras/ formal specifications can 
be produced _ which are truly independent of an implementa- 
tion; many implementations of the specification can be 
c.reated which emulate a formal algebraic specif ica tion . In 
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A. A REVIEW OF ALGEBRAS 

An algebra consists of a set, called the ca 
algebra, an operator defined on the carrier 
guished elements of the carrier, called the cons 
are normally represented using a bracketed t 
example, the addition operator on integer 
expressed as follows: 

< I , + , 0> 

The carrier set»^can be of any one type we wi 
uldte such as real numbers, integers or charac 
For the addition operator on integers, the sa 
identified by the capital letter I and the ele 
carrier set are the integers. The di sting ai sned 
is z e ro . 

An operation is a mapping taking one or more 
the carrier to an element in the carrier. For e 
addition operator on integers will take two inte 
them to an integer as shown in Figure 2. 1 . 

It is common practice to refer to a specif 
algebras. The members of a particular class h 
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signature or "arity” in tiitir oneratcrs [Ref. 2]. io:. 
ix'iStanca/ the subtraction/ addition ani mu Itiplica ti o.: oper- 
ators on integers are members cf the same ciass since tney 
have the same signature; they map two integers to one 
integer . 



Integers 




Figure 2.1 Mapping of integers. 

The constants or distinguished elements of the Cdmer 
usually have special properties. The numoer zero in th.e 

integers has a special property in regards no the addition 
operator; any number added to zero will man oack no that 
number as shown in Figure 2.2 - Algebraic specification:;: 
will not explicitly deal w it n distiiiguisnea elements. 
Instead/ constant operators are used to describe the distin- 
guished elements. This is done to achieve implement at ion 
independence in the specification. 

An algebra is not usually interesting unless it has some 
specific structure. The structure is defined by axioms. 

the addition operator as define 



Using the above example/ 
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Figure 2.2 A CoEstant i-lapping. 

will not Le useful if every application of the operator 
mapped an element to the same element. Therefore restric- 
tions on the behavior of the addition operator are defined 
which limit the mapping. Later it will be shown how axioms 
define the behavior of operators in an algebraic 
specification. 

B. SIGSA OR MANY SORTED ALGEBRAS 

An algebra with one carrier set and mapping is not 
particularly useful for the purpose of specifications. For 
instance^ in defining a stack as an abstract lata type using 

algebras# we would not want to be limited to one of 

data the stack contains such as a stack of integers. Instead 
we would like to talk about a stack of integers# reals, 
booleans# etc. Therefore in specifying an algebra for a 
stack# a ’sort' set would be defined. Each cilement of the 

sort set would be an index to a carrier set; the sort would 

identify the carrier set. A stack data type can then be 
defined as having a sort set as follows: 

S= {integers , boolean #stack#reals} 
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Zach eieneat in the set S re^^^resents a carrioi, . mov. *t li, 
possible to define a stack of reals, integers, and. boolean 
values. Notice that a stack also is a sort; a stack is a 
different object after operations are perforned on it. As. a 
result, stack is also a carrier set. 

In addition to the many sorts of an algebra, it is 
desirable to have various operators on the sorts. Or.iiratcrs 
on the data type are defined by mai^pin^s from zero or rrore 

elements from carrier (s) to an element in a carrier set. 

Using the stack example, the push operator can be defined 
as : 

push: integ er , s tack -> stack 

The meaning of this operator is that given an element from 

each of the carriers identified by integer ai\a stack, the 

push operator produces an element in the carrier ideiitifiel 
by stack. This is depicted in Figure 2.3 . 



antegers 




Figure 2.3 The Push Operator. 
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The operators j.n ai. ai^earaic at'Scif icati ju die -jivti. oy 
a sorted signature,- Siqraa, or o^-erator domain, wnich is a 
family of sets. Each set of the family contains a partic- 
ular domain for a group of operators. These ail have the 
"arity" discussed in the previous section. Usin^’ the srivck 
example, the arity Sigma (inte ger stack, stack) defines a 
domain for those operators which md£ an integer and a stack 
to a stack. The push operator would be a member of this 
domain. Any other operator which took an integer and a 
stack and mapped it to a stack would have the same arity. 

The pop operator would be in the set of operators given 
by the arity Sig ma (s tack , sta ck) . If there was an operator 
which removed two or more elements from a stack, it would 
also have the same arity. An interesting point licre is than 
the integer which is removed is a side effect which must r-o 
described in the equations for the operator. All of the 
operators defined using the sort set are coilec ti vel.y known 
as the Sigma signature 

Given the above, a specification algebra consists or a 
sort set S, a Sigma signature on the sort set, and named 
operators for each signature. Algebras defined as such are 
called many sorted algebras or Sigma algebras 'Ref. 2]. 



C. BOOLEAN AS A SIGJIA ALGEBRA 

In order to explain tne use of axioms, a devt;lopmtnt of 
the Loclean data type as an algebra is preseiittl. It will 
specify how an implementation of boolean logic should behave 
if used in a program or a machine. 

An appropriate sort name for the boolean data type would 
be bool and the cor responding sort set S would be {bool} . 
Bool is the only sort type reguired to specify the boolean 
data type. The carrier set that booi identifie.s will contain 
two elements {T,F}. Although two specific elements of the 
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carrier have been descriLed here, an 1 w.jI enenno r :aay choose 
different rejjresenta tions for the elements of rae carrier; a 
carrier vith elemeiits {0,1} would work G'^ually well. In an 
algebraic specif icaiioii, the eleiiieuts of tht carrier are not 
specifically defined so the iaplementor may choose any 
representation for carrier elements. In this way, a speci- 
fier can achieve implementation independence. L'ovh- vc?r , for 

the purpose of clarity, the elements of the carrier v.ilj. be 
used in the boolean example to define the opei.ators. 

The five boolean operators used in tliC s pecif icat ion 
will be as follows. 

1. true - Returns a value of T. 

2. false - Returns a value of F. 

3. not - Returns the negation of a value. 

4. implies - Implication 

5. and - The logical ’and’ operator. 

The following notation will be adopted for operators to 
describe the operand sorts and the resulting sort. 

For Sig ma (lambda, bool) 

true ; -> bool 
false : -> bool 

For Sig ma (bool, bool) 

not: bool -> bool 

For Sigma (bool bool, bool) 

and; bool, bool -> bool 
implies: bool, bool -> bool 

The notation here is the same as that used to describe the 
push operator in the last section and will be tne same no ca- 
tion used in the specification lan-juage presented later. 
For the signature Si gma (lambda , bool), tlie notation means 
the ’’true” and "false" operators produce an element in the 
carrier set identified by bool. Lambda is used in 
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'conjunction witii constant operators; constai.t c'^t:i.atcrs 
always produce the same element and they appear to produce 
something from nothing. The "ncn" operator takes an element 
from the carrier set identified ly nool and produces an 
element in the bool carrier set. Tne "and" and "implies" 
signature would be Sigma (bool bcol^bool) . That means, given 
two elements in the carrier set identified by bool, the 

"and" arrd "implies" operators produce an element in the 

carrier identified by bool. 

The sigma algebra for boolean at this point is not very 

interesting. This is because the operators have no restric- 

tions on their behavior. Consequently most implementations 
of boolean usiiig just this specifica tion would not be 
useful. For example, the "not" Ot-erator would be correct if 
it took, any element in the carrier set and produced the samf^ 
element. A more useful Sigma algebra would put restrictions 
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4. and (false, V) = false 

5. implies (v 1 , v2) = not (and (v 1 , not (v2) ) ) 

Motice that the axioms were written without using a 
explicit reference to carrier set elements; by not usinj T 
or F the data type achieves implementation independence. 

Implementations of the tcolean data type are now 
required to mimick the axioms when operators are applied. 
For instance, the negation operator, "not", now behaves as 
expected and any implementation would have to reflect axioms 
one and two. Axiom one shows the effect "not" has on an 
element in the carrier set. Axiom two further aefines the 
behavior of "not" by showing that any element in the carrier 
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which is ojerated or. b" ti.e ‘’not" o^craiior twi-j-- 

produce the same element. 

The "and" operator behaves as depicted by epuations 

three and four; given any value v1 "anded" witn the vai’ie 
produced from the "true" operator will result in tnat value. 
Implies is defined by axiom five as being the same as l. 
combination of "not" and "and" operators using too same 
carrier values. 

Note that with the exception of axiom oi.c^ all ti.<? 
axioms involve variables v, v1 and v2 which car. be assigned 
ail values from the carrier set defined for the opecator^j 
"and" "not" and "implies". The axioms form the oasis of ail 
the expressions that can be created using the variables and 

members of the carrier set. This means that an expression 

which is built from other expression is permi-ssable if it 
reduces to an element of the carrier set throigi. the 

application of the axioms. 

To illustrate this, suppose we had an expression 



not (and (not (vij ,v2) ) 



If V 1 is assigned the element T and v2 
element F, then the expression becomes 
axiom cne: 



is d.ssigned the 
tne foliov;ing by 



not (a nd (F, F) ) 

Inis further reduces to not(F) by axiom four. .^.xicm one 
implies that this reduces to T, an element of the carrier. 

All the permissible expressions tnat can be constructei 
from the operators and elements of the carrier arc collec- 
tively called the term algebra. The algebra that represents 
all the expressions that can be made up of variables ai. J 
operators is called a free a^e_^a [Ref. 2]. 

It is now possible to define a specification as a "pres- 
entation". A presentation consists of a sort set, an 
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operator doiaain Siyma, and axioas on the oper-itcrx. A pres- 
entation will be the basis for the sped ficatior. lar.gua'jt^ 
S^jecian j , presented in the the next chapter. A specf icat ion 
developed from Speclang is comprise of one or more presenta- 
tions and each presentation is known as specific atio n 
modules , 
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III. A SPECIFICAIION LANGUAGE 



Liskov and Zilles [Ref. 4] nave developed criteria ior 
evaluating a formal specif ica tion language. Their v.’or}' 
focuses on the underlying mechanism used in formal r-pecifi- 
cation. They compared approaches using alv^ehras, finite 
state machines, mixed mathematical disciplines, etc. The 
criteria used in their comparisons are: 

1. Formality - The language must te precise and 

rigorous. 

2. Constructability - It should be easy to construct a 
specification from the language. 

3. Comprehensible - Is the sped f ica tion relatively easp 
to understand? 

4. Minimality - The spe cif ica tion generated should 
define its meaning with a minimum number of state- 
ments. One flaw of formal specif ica tioiis is that they 
frequently require more statements than the program 
they specify. 

5. Applicability - Can the language oe used for a wide 
range of specif ications? 

5. Extensibility - A minimal change in concept results 
in a similar small change in a specif icat ion. 

The rigorous underlying mathematics for aigeiiras satisfy 
the formality criteria and the axioms restrict tae amount of 
information required to explain desired behavior, thus 
satisfying minimality. Also, it appears that any desire] 
change in behavior requires a minimum of additional axioms 
or minor modifications to the existing oiies. As for applica- 
bility, algebraic specifications are being used for abstract 
machines, data types, and programming languages, 
indicates a wide range of applications. 
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Algebras, in Liskov and Zille's opinion, sati?5ti3d all 
of the above criteria except coirprehensibilty and construct- 
ability. These deficiencies can be reduced to a aanageabie 
level. The following proposed language, Speclang , will mini- 
mize these problem areas. In this chapter, it will be shovn 
that a complex specification can re modularized; broken into 
smaller units which enhance cons truct ability and 
comprehensibilit y . 

There are many underlying issues involved in using alge- 
bras for specifications which have not been resolved. 
Issues such as proving specifications correct, infinite 
versus finite specifications, implementation and ot.^er 
complex issues will net be addressed. The following sections 
are to familiarize the reader with the grammar for Specaaiiq, 
parts of a sped f ica tion produced from the Speclang grammar 
and a brief explanation of the uses of t’le various parts. 

A- SPECLANG GRAMNAE 

Before presenting the various parts of a specification 
constructed from Speclang, an introduction to tlie grammar is 
presented. Appendix A contains the complete grammar for 
Speclang. The production rules are written in a modified 
Eackus-Naur (3NF) notation. The meta-symbols in t ht produc- 
tion rules are used to form the construction of a spec j.-.iv-n- 
tion and do not appear in the final specif ic ation. An 
explanation of the meta-symbols used to produce terminaj. 
strings in the grammar are as fellows; 

< > - A name enclosed by pointed brackets indicates a 

non-terminal in the grammar. 

’ ' - Strings in guotes indicate terminal strings. 

( ) - Rounded brackets indicate the scope of a modifier 

symbol. 



22 



* - -he Kleene closure iQodixier niay follow eiil.er roj.._eo 

hrackets, terminals or non-terminals. It means than ‘zero ur 
more of the expressions, terminals or non- terminals may be 
prod uced . 

+ - The alternation modifier is used like the Kleene modi- 
fier. It means that one or more of the expressions, 
terminals or non- t er minals may be produced. 

1 - The selection modifier indicates a choice of non- 
terminals, terminals oi expressions. It is used between two 
choices. In order to clarify the selection, rounded brackets 
enclose the selection. 

? - The option modifier indicates that the terminal, 

non-ter minal , or expression is cptionai and can be excluded. 

-> - The production symbol indicates what the non-terminal 
on the left hand side can produce. 

A production rule consists cf a non- ter minal followed by 
a production symbol followed by an expression. An expressjon 
is comprised of terminals, non- ter minals , modifying symbols, 
and may include other expressions. The fc Hewing produorioj. 
rule will be used as an example througnout tlie remainder of 
the thesis: 

<module_spec> -> <spec_header> 

( <newline>< indent >< par aui_bloo k>) ? 

< new 1 i ne ><i n de n t ><s pe c_ bo dy > 

This rule defines a specification module. The module would 
begin with a specification header followed by an optional 
expression that contains a carriage returii, iiidentatioi. and 
a parameter block. Because it is an optional expression, it 
may he omitted. After the expression, another carnage 
return and indentation occurs followed by a specification 
body . 
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Che grammar for Soeciang inciudfes ir.dent at ior. .i.t ; 
carriage returns to permit a formatting of the specifica- 
tion. This was done to create a standard format which will, 
hopefully, increase the readalility of a specification. 

A specification is complete when all the strings in the 
specification are terminal strings. This is accomplished by 
starting with a nonterminal and substit ut ing the expression 
appearing on the right hand side of its production rule. The 
remaining nonterminals are then substituted until all the 
strings are terminal strings. For example', starting with 
the nonterminal <module_spec> and substit utiii g ti;e right 
hand part of its rule results in the following: 

<spec_header> (<newline><indent><param_niock>) 7 
<newlin eXinden t>< spec_body> 

The rule for a specification header is; 

<spec_hea der > -> 'SPFC' <spec_id> ’IS’ 

Its right hand side is substituted into the right hand side 
of the above strings to produce: 

’SPEC’ <spec_id> 'IS' (<new_line> <indent> <pciraE_block>) ? 
<newline> <indent> <spec_body> 

<nevline> and <indent> can be interpreted as carriage rrrura 
and a tab respectively, excepr when it followed by a 
modifier, and make the developing specif icaticn appear as: 

SPEC <spec_id> IS (<newlineXindent><paraa_biock>) ? 
<spec_body> 

In the lexical grammar for Speciang, <indent> is treated 
either as one or more tabs or spaces. This was done to 
permit the degree of indentation a specifier desires. Once a 
indentation has been selected, it should be continued 
throughout the specification. For instance, if one tab is 
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use a to 


in 


dent 


a 


line. 


then 


every time 


inient is encounterej. 


one tab 


sh 


ould 


b e 


us ed. 








Since 


<par am_ 


biock> 


is 


opticnal it 


can be eliminated to 



prod uce : 

SPEC <spec_id> IS 
<spec_ to dy> 

The suhs titut ions are continued until ail string's art, 
composed of terminal characters. 

The first nonterminal string in Speclanc is <coD;p_spec> . 
This denotes a complete specif ication. As mentioned in the 
previous section a specif icatio n developed from Speclang is 
made up of modules. Each module in itself is a specifica- 
tion. To reflect this the right hand side of the production 
rule for <comp_spec> is <module_spec>+. In other words, a 
complete specification is made up of one or more 
specification modules. 

B. PAETS OF A SPECIFICATION 

As mentioned in the previous section, a complete speci- 
fication is made up of one or more specif icat ion nodult-S, 
Each specification module is an algebraic specification, 
which can be viewed as a sutspecif ication of the complete 
specification, and has three distinct parts - heaaer, signa- 
ture, and axiom parts. Each specif ica tio n u.oduie is eitaer 
"primitive", "extended" or "parameterized", j'riaitlve 
modules do not import other specif Ication modules wr.il e 
extended modules do import other specif ication modules to 
create a new specification. "Parameterized" nodules art 
used to minimize a specif ication and can be either pri ir.it Iv- 
or extended. 

A specification is started with primitive modules. These 
modules are used to create other modules througn the 
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ts described in the next sections. The Idot s^'e^i- 
ficatioii module defined in a complete speciii cat ton^ in 
effect, consists of all the other specif icat ion modules 
since it is built frcm the previous nodules. The following 
section describes and discusses each part of a specification 
module. 

1 . Hea de r 

The header identifies the name of the s pt;cif icat ion 
and sonetimes contains a "modifier”. "Primitive" nodules in 
Speclang contain no modifiers and the fcmat is as follows: 

SPEC <spec_id> IS 

[signature part} 

[axiom part} 

<spec_id> is a slot for the particular name of that 
declared specification. The body of the specificat ion, which 
contains the syntactic and semantic part, follows urdernecith. 
the header. When used, the modifier is directly unaer the 
header. Its purpose 'is to import other specifications into 
the declared specification. Ihe modifier is tne primary 
method used to combat the complexity of an aiuebraic speci- 
fication. It will be presented after the other [arts of the 
specification are introduced. 

2 • Signa t ur e Part 



The 


signature part 


of an algebraic 


s pe cif icat ion 


contains the 


declarations 


for sorts 


a nd 


operators an 1 


defines the 


format and composition of 


the 


operators. It 



corresponds to the signatures discussed in chapter two. 
a. Sort Declarations 

In Speclang, the format for declarinj sorts is: 
SPEC <spec_id> IS 
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sort 



<sor t_id> ; 
<sor t_id> ; 



<sort_id> is the slot for a particular 
name. As explained in the previous chaprer^ the sort will 
identify the carrier (s) used in the operators. All of ,rhe 
sorts declared under the header SORTS define the sort set. 



b. Operators Declaration 

The operators declaration can contain up to four 
different types of declarati ons : 

1 . Primitive 

2. Derived 

3 . Hidden 

4. Error 

These o^^erator type names are used as headers ro 
each group of operators declared in Speclang. The basic 
format for an operator is: 

<op_id> : <sort_id>, <sort_id> ... -> <sort_id> 





An 


operation , 


as explained in 


J--L/ Cdi; 


map zero 


or more elements 


from a carrier set (s) identified 


by the 


sort 


name(s) to 


an element of 


a carrier set 


identified by 


the sort name 


m 






T 


specification 


with sorts and 


0 . erators wojli 



appear as follows: 



SPEC <identifier> IS 
SORT 

<sor t_id> ; 

OPERATIONS 

PRIMITIVE 

<op_id>:-> <sort_id>; 

<op_id> : <sort_id> , <sor t_id> -> <sort._id> 



27 



HIDDEIi 

<scrt_id> -> <sort_id>; 

EREO K 

<op_id>: <sort_id> -> <sort_id>; 
DERIVED 

<op_id>: <sort_id> -> <sort_id> 



( 1 ) Primitive Operators. Primicive cperatorj 
are newly defined operators and cannot be cons true txid iron 
any other operators such as the derived operators describe.! 
next. Primitive operators may involve sorts from other 
specification modules and usually contain at least one sort 
from the specification in which they are leclared. 

(2) Derived 0£eratgrs, Derived operators are 
operators which can be produced from other operators. They 
are declared so the implementor of the sped f ica cion is 
aware that their existence is rot essential. For instance, 
in the boolean sped f ication , if the ”not", •■and'* and "oc'* 
operators are defined, it is not necessary to include an 
"implies" operator since in predicate logic "implies" is 
equivalent to "not" A "and" E. The benefit in having a 
derived operator, such as "implies", is to mininize the 
specification and, in many cases, make the specification 
more comprehensible. In the boolean example, "implies" is a 
well understood operator and using it in other s ^.e df ication 
modules will make the modules mere readable than if a combi- 
nation of "not" and "or" were used. "implies" would be 
declared under the DERIVED header. 



(2) Error Operators. The proper handlinj of 
errors is crucial to a specification. However, it is 
frequently the case that specif icat ions for languages, data 
types, programs, etc. do not precisely define what should 
happen when an error is encountered. This is carte blanche 
for the implementor to do what he thinks is appropriate. In 
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the worst cases, noti.xn^^' is done, pemttiria Lira-r*- 
conse guences. 



circuffls tances 
operands and 
example, in 
integers, tie 



A specif ica t ion should adlress tncse 

where the operator may not make sense on the 
define precisely how to handle then. ioj; 
the specif icat ion for a data type "stacK’‘ of 
sorts and operators would be as follovs; 



SPEC Stack IS 
SORIS 

int ; 
stack ; 
OPERATIONS 

PRIMTIVE 



new ; 


s tack ; 


> 




push : 


: in t , 


stack -> 


pop: 


s tack 


-> 


stack ; 


top : 


s tack 


-> 


int ; 



The "new" operator creates an empty stack 
and the "push" and "pop" operator behave as would be 
expected. The "top" operator allows tne user to view the top 
element of the stack. 

Problems occur when a user attempts to 
"pop" a "new" stack or view the first element of a "new'* 
stack. These are valid -operators since "new" returns a stack 
and the "pop" and "top" operators are defined on a stack. 

It would seem reasonable to introduce a 
value "error" to each carrier set to define «rror cendi- 
tions. Guttag [Ref. 3] proposed this approach. The result 
would be eguations which specify what are error coi.di lions . 
Axioms pop (new) = error and top(r.ew) = error woulc s C;=:r'! ijn -iy 
resolve the problem. Guttag also required e^^uations which 
defined the propagation of errors. Therefore pus h ( error , s) = 
error and push (n , err or) = error would be introduced into the 
spec if ica ti on. 
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?asel i’.ds deconstrateu 1 ht; i r...i i<.i ^aacy oz 
this aj^proach [Eef. 5]. Ihe valia £''y.ia:.io:.;- 

top (push (n, error ) ) = n and t op { pu sh (n ^ error) ) = error can be 

produced from the axioms which imply n = error for any n. 

The approach adoptei in Speclanp is th-. 
one used ty Fasel and developed by Goguen [Ref. 2]. Tnis 
involves introducing error operators into the s^>ocif ica cion . 
These operators will produce error messages. In the stach 
operator, we would define error operators ”topnev' and 
"underflow*' which produce carrier values inlSjtr a:'d stach 
respectively and also generate error messages. In ipociaag, 
the error operator will be declared under the error operator 
title. Using the stack specification, the declaration would 
be as follows: 

SPEC Stack IS 
SORT 

int ; 
stack ; 

OPERATIONS 

PEIillTIVS 

new; -> stack; 

push: int, stack -> stack; • 

pop: stack -> stack; 

top: stack -> int; 

ERROR 

topnew: -> int; 
underflow; -> stack; 

The axiom pcrtiori of the sped ficacio-i 
would use these operators to define error conditions. 

{^ ) Oper at ors. Unfortunately, it is 

not always possible to have gust operators for the user. 
Some operators are required in order to define the user 
operators. Majster demonstrates this with a stack 
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incluies operators th 



sp ecr f icat roil wnicu 
to view anv element o. 



, t; 



the stack without J.is'carnii 



stack. [Eef. 6]. In order to define these oror ators, it is 
necessary to define a "current position" which point to a 
particular element in the stack, not necessarily the cop 
element. The new operators are "down" which laovc-s the 

current position down’ one element in the stack, "return" 
which moves the current position to the top of the stack, 
and "read" which will give the value of the eloment at which 
the current position is pointing. Push, pop and top can .juiy 
he done when the current position is on ti.e top eltuent. 
Using just the operators availalle to the user, it appedrs 
that an infinite numler of equations are required tc define 
the meaning of reading each element of the stack (if tn.e 
stack is considered an infinite specif icat ion) . fhe 

following are just a sample of the equations required; 

read (push (n 0, L) = nO 
read (dow n (push (nO , p ush { n 1 , L) )) ) = n1 

read (down (down (push (uO, ^ ush (n 1 , p usn (ii2 , L) ) ) ) ) ) = n2 



Enumerating all the required equations i*;. 
not particularly enlightening for the impieraentor and is a 
gross violation of liskov and Ziiles minimality critsria. 
To solve this problem, hidden operators are intrcuucei 
[Eef. 7]. In Majster’s stack, lasel proposed usir.y a hliien 
operator "append". Append adds a new element to the top of 
the stack without changing the current position. If the 
current position is at the top of the stack then append has 
the same effect as push followed by down; 

append (n, new) = down (pusn (n, new) 
append (n2 , push (n1, L) ) = down (pusn (n2, push ( n 1 , L) ) ) 

If the current position is other than the 
top, then axioms would show that appending is unattached to 
the down operator; 



a^^peni (n^ >2owi* (L) ) 



down (a ppor i (n , L) ) 



The read operator can then be detined in 
terms of the read and push operators; 

read (push (n ,L) ) = n 

read (append (ii, 1) ) = read (L) 

Append would rot oe an operator available 
to the user. Its creation was to allow a finite specifica- 
tion of an otherwise infinite specif ica tion. Hidden opera- 
tors lihe append would be declared under the header HIDIZN 
to alert the specifier of its special use. 

Hidden operators present problems when 
overused. In particular, the;y suggest an implementation 
[Ref. 5]. The append operator is an example of this. The 
read operator problem may be solved in ways other tiian using 
append that is less suggestive in an implementation. 

In Speclang, hidden operators are declared 
under the "HIDDEN" header. 

The axiom part implicitly describes the behavio:. of 
the previously declared operators. It is the mosc diiiicaLt 
portion of a specification to construct; developing the 
axioms to reflect only the desired behavior and no more is 
tricky. 

In Speclang, the eguations which define operator 
behavior are placed below the header "AXlOH". Tae vaj.iandes 
used in the operator are assumed to be of sort t ypes jocd an 
the declaration of the operator. The format for axioms is 
as follows: 

SPEC <spec_id> IS 
SORTS 

sort 1 ; 

OPERATIONS 
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PRinirivz 

opl ; scrt1-> sort 1 ; 

AXIOMS 

oj: 1 (x 1) = X 2; 

Ihe equations are composed of a left side and a 
riyht sice separated iy an equal siqn. The equal siqn wOes 
not mean the two sides are equal. It signifies that th'..- 
terms that are produced from the operations on each side ara 
in the same equivalence class. Although this is an important 
concept for the underlying theory of algebraic specifica- 
tions, it is not vital to the person developing a specifica- 
tion. Another way of viewing equations is that each operator 
is defined by an equation that shows wnat happens wnon the 
operator is applied. For example, in defining the ’’pash” 
operator on a stack S, we would want to show that for any 
element e, push (3, e) produces a stack with e on top. Ih e 

specifier should know that the top of a stack is also 
related to the "pop" operator. The solution then in defining 
"push" is to relane it to the "pop" operator as follows; 

pop (push (e ,3) ) = e 

The implicit definition sof Lenavior througii alge- 
braic axioms provides independence froii?^ implementation but 
also creates problems in constructing a specif ication. 

^ Mod ifi ers 

When developing a complex program, a programmer will 
modularize functions. The benefits are a more readable 
program and the program is easier to develop and maintain. 
An algebraic sped fication using Speclang also can be 
developed this way. 

Burstall and Goguen [Ref. 8] presented a structured 
language which effectively breaks a specification into 
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smaller ir.ore manajeabie urits. 



^ V-i O. 



" theory_Iui Idiny ” iuouifieLS whicii permit tne specilxer to 
modify previous specifications. Fasel used tiieir theory- 
building modifiers to develop his specification of a 
program. The proposed modifiers to accomplish this were 
combine, induce, extend and derive. Speclang uses only the 
extend modifier to create specifications. 

The extend modifier adds new operators, tguatrous 
and sometimes sorts to a specification. Farther more, the 
extend modifier allows the specif. ier to combine two or more 
imported specifications to create the new so eciiicdtioii. 
Fhen two or more specifications are combined, ail of their 
sorts, operators, and axioms are lumped together to 
new specification; this method is a shorthand 
defining the sorts, operations, and axioms which minimize 
the specification. 

In order to show the use of tiie extend 
without combining, Fasel ’s example of the 
specification is presented: 



lorm the 
w ay of 



odlf ier 
M dturai 



SPEC Natural IS 
SORTS 
nat ;# 

OPERATIONS * 

9 

zero : -> nat ; 
succ: nat -> nat; 



Ne can extend the specif ication with addition and 
multiplication to create a new specifica tion Natplus; 



SPEC Natplus IS 
EXTEND 

Natural ; 

WITH 

OPERATIONS 

PRII1ITI VE 
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ddd: nat/nat -> nat; 
mult: nat,riat-> nal; 



AXIOMS 

add (n, 0 ) = n ; 

add(succ(ra) ,n) = succ (add (n,a) ) ; 

mult (0 , B) = 0 ; 

The extend modifier draws in all the operators 
axioms and sorts from the specif ica tion name followin 
extend and in this case from Natural. Additional sorts 
operators, and axioms are included follov'diig rhe headin 
"WITH". 

If the extend modifier v«as used to ccmLine specify 
cations as well as include new sorts, operations, an 
axioms, then Natplus could have been extended with spociii 
cations Boolean and Natural to produce the followin 
specif ic at ion: 

SPEC Nat pi us IS 
EXTEND 

Boolean ; 

N at ural ; 

WITH 

OPERATIONS 

PRIMITIVE 

add: nat,nat-> nat; 
multiply: nat, nat -> bool; 
eaualto: nat, nat -> bool; 
if_then_els e: bool , nat , nat -> nat; 

AXIOMS 

add (n, 0) = n; 

add(succ(m) ,n) = succ (add (n , m} ) ; 
multiply (0 , n) = 0 ; 
multiply (n , succ (m) ) = 

add(n, multiply (n,m) ) ; 
equalto (0, succ (m) ) = false; 
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eoudlto(0,0) = true; 
equal to (31/ ro) = true; 
if_ther._slse (T /V 1 / v2) = v1; 

if_then_eise (? /V 1 / v2) = v2; 

In ti.is case we have two specifications / Boolean and 
natural/ which are used to define the Natplus specification.. 
All of the specifications declared by the identifiers 
between "EXTEND" and "WITH" are combined to produce the new 
specification. In addition/ new sorts, operators and equa- 
tions are defined on the cor.bined specif icatior./ and are 
declared following "WITH". 

Although the Natplus specification could have been 
easily defined without the extend modifier/ a larjer/ more 
complex specif icat ion would be difficult to read and picb- 
ably impossible to understand. For example/ the abstract 
machine specification described in chapter I has one speci- 
fication module which represents the final specif ication. 
Its extend modifier combines four other specification 
modules and extends them with approximately one hundred 
other operators and seventy equations. If this machine was 
described without the extend modifier/ then each cf the 
combined specification’s sorts / operators/ and axioms voui.i 
have to be included in the s pecif ica tion . Since eacn of th : 
combined specifications were also extended, each ci tne 
specifications imported to create them would also be 
included. The result would be a specif icatio n ccntair.inq 
hundreds of operators and equations/ making the 
specification incomprehensible. 

Before a specification can use another speciiicataon 
in the modifier/ the specification being imported must have 
already been declared. In the above examt^le, Natplus, 
Boolean and Natural, would have already been declared in the 
complete specif icaticn. 
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One method of minimizing a specif ic itioii is chcoagh 
the use of parameterized modules. Goguen suggested this 
technique and Ganzinger [Bef. 9] explored it in deptli. Ihe 
rasic concept is to use a procedure like specif ica ti Oii to 
create a new specif ication. This is a particj lardy jsefu_ 
technique when many specif icati cns tend to be repeated such 
as in the case of a list of integtrs^ characters, re>il 
numbers, etc. Instead of a s pecif ication x": or each cy.e of 
element, a generic template would be used to describe how a 
list of a particular type should behave. The para sets riCed 
specification for lists can be invoked by passing the speci- 
fication for reals, integers, characters, etc. producing an 
instantiation of the parmeterized specification which is a 
new specif icat ion. 

Many issues are still unresolved ii. paraifiet erizt^ i 
specification which will not re addressed nar-L.- [Ref. 9]. 
Before using parameterized specifications tliese issues 
should be understood. 

The parameterized module coixsists of two primary 
parts. These are the parameter block and the s pe cif j.can ion 
» block- The parameter part of a specification cefinos what 
may iome inside a parameterized module during an instantia- 
tion. An instantiation is tht: passing of an actual 

specification to a ^xarameteriz ed specif ic at ion. 

The parameters can be viewed as the interface to the 
outside module which is invoking tiie procedure. It consists 
of sorts, operators, and axioms ana is announced by ihe 
header ''PARAMETT RS» . 

The specification part is like the c^^'ocif icat ion 
body used in primitive specif icat ion modules. It consists 
of sorts, Ot-erators and axioms and is declared by the header 
"DEFINED 3Y". 
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Ahen tho par aaeterized sped f ica tioi. is ir.vcked ti-.e 
formal parmeter’s sorts, operators and axioms are replaced 
by the actual parameters passed froai the designated 
specification. 

In Speciang, the format for a parameterized 
specification would appear as fellows: 

SPEC <identifier> IS 
PARAMEIEB3 
SORTS 

<sor t_ tody > ; 

OPERATIONS 
<op_bo dy > ; 

AXIOMS 

<axioia_body>; 

D Eli NED BY 
SORTS 

<sort_tody> ; 

OPERATIONS 
<op_body > ; 

AXIOMS 

<axioiD_body> ; 

Ganzinger illustrated parameterized specif ications 
by using the list example: 

SPEC Lists IS 
PARAMETERS 
ENRICH 

Boolean ; 

WITH 

SORTS 
eleia ; 

OPERATIONS 

PRIMITIVE 

egual: elem,€lem -> bool; 



38 



i f-then-e ise : i^ooi/ eie-» , elen -> el-^a ; 

AXIOMS 

equal (e,e) = true; 

DEFIN3D BY 
SOFTS 
lis t ; 

OPERATIONS 

PRIMITIVE 

lemp ty : -> lis t ; 
isempty: list -> bool; 
cone: elem^list -> list; 
edr: list -> list; 

if- t hen-else ; b col, lis t , li s t -> lisu; 
first: list -> list ; 

AXIOMS 

cdr(lempty) = leiafty; 

edr (cone (e, 1} ) = 1; 

car (if _then_else ( t, 11 , 12) ) 

= if_then_else (b /Car (11) ,cir (12) ) ; 
isempt y (lempty ) = true; 

isempty (cone (e, 1) ) = false; 
isempty (if _ the n_ else ( b, 1 1 , 12 ) 

= if_then_else (b, isempty (11) , isempty (12) ) ; 
first ( lempty, e) = e; 
f irst (ccnc (e,l) , e ’) = e; 

first ( if_then_fcls€ (b, 11,12) ,e) 

= if _ X hen_else (b, first (11, e) , first (12, e) ; 



This parameterized specif icaticn is invoked by using its 
name and brackets arcund the specif ica ti on which is to be 
used for the instantiation. Therefore, if a specification 
for a list of natural numbers was desired. Lists (Ndtural) 
would invoke the parameterized specification for list. In 
order for Lists to be correctly j.nvoked, the Nat 
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srecif icdtioL must "match" the iocmai parameters of Lists. 
In Speclang/ the sorts are matcx.ed under the header "ACTUAL 
SORTS" and the operators are matched under the header 
"ACTUAL OPERATIONS". Under each of these headers the sorts 
and operators that are to replace the formal parameters are 
positioned to the left of an "IS". The formal parameters the 
actual parameters are replacing are positioned to the right 
of the "IS". In Speclang, the matching parameters are 
announced at invocation. Using the natural numrers 
invocation# it would appear as follows: 



Lists (Natura 1) 

UEERE 

ACTUAL SORTS 

nat IS elem 
bool IS tool 



ACTUAL OPERATIONS 
equal IS equal 

if_then_else IS if_then_else 
and IS and 
not IS not 



Note that the parameterized specifica 
extend field in the parameter blocx. When this 
parameterized specification must be invoked wit 
operators that also match the specif ications 
imported by the extension. In the List example 
and operators in the Boolean specification were 
the invocation. 
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IV. SPECIFICAIION EDITOR 



In order to facilitate writing specifica tion^: , a syntax 
directed editor was designed to format a specif icat ion 
created from Speclang. The editor is rased upon ideis from 
Davis [Ref. 10] and HacLennan [Ref. 11]. .It is tatie driven 
in that a grammar is input and parsed into separate y reduc- 
tion rule trees. The production trees are tiien use! t' 
create a specification tree. Ej usin 9 the table laetnod, 
flexibility is gained in altering the grammar vitrout 
affecting the editor. IlacLennan’s editor and the idea 
presented by Davis was to create an internal tree xroi ihe 
grammar which was annotated; the tree was in a parsed forK 
which could be used to generate the machine code. The 
Specification Editor presented here was designed to create a 
syntactically correct specification and to mate the inter- 
face with the user simple and friendly. The internal tree 
created by the editor is not annotated as prescribed by 
Davis and iMacLennan. The editor could be modified to incor- 
porate annotations which could transform the syntax tree 
created by the tree to an annotated tree. A grammar grammar 
was developed for the parser which is based on the modified 
BNF notation presented in chapter III. 

The grammar used in the editor is the same as that in 
appendix A except for the following: 

1. Comments have not been incorporated. 

2. The input grammar cannot have selection invoiving 
expressions. For example, the following production 
rule would not be acceptable since the right i.un d 
side contains an expression with the selection: 

<spec_block>-> {< param_cali><crXindent >) i <sp ec_body >) 



This restriction was iaiposea for two rtasons; to 
force a clear display selection and to rec.uc.‘_ the 
proliems involved in programming the recursive 
descent parser. This restriction is not severe since 
the right hand side could be rej, laced with a 
selection such as <param_call> creating two rules; 

<module> -> (<par ara_cali> j <spec_body>} 

<param_call> -> <call_block> <cr> <indent> 

3. The rules were modified to reduce th^ number of 
selections available. For example, the rule for a 
<module_spec> is as follows: 

<mod_spec> -> <spec_headerXmodif ieLS>? <sptc_bcdy> 

This was combined with the rule for <spuc_].Gader> to 
create a rule: 

<mod ule_spec> -> ’SPEC’ <spec_id> ’IS* <ir.dent> 
<crXmodi fier s>? <spec_boay> 



A. AN EDITING SESSION 

This section will describe an editing session. The 
edition is initiated by entering the name of the editor,- 
Speced. A prompt appears requesting the name of the fiJ.o 
where the user had stored a tree from a previous editing 
sess ion . 

The screen is cleared and the first production rule’s 
right hand side is displayed on the screen in an unparseu •” 
form. The video is then reversed on the first nonterminal or 
modifier which an input selection can effect. All of the 
strings which are displayed in reverse video are reierred to 
as the selector field. 

For example, if <moduie_sp ec> was the first rule, thei. 
the display would be as depicted in Figure 4. 1 . 
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Figure 4.1 Display of the Rule <module_spec> . 



In this instance, the video for <spec_id> would be reversed 
denoting the selector, and the bottom of the display would 
show the selections available. 

The selector is directly related to a selection poirter, 
sel_ptr, which points to a node in the specir rear io.n tree 
being edited. The nede at which the sel_ptr is porntiny is 
referred to as the current node. The current node is shew:, 
at the bottom of the display fcllowinj ’’NODE:”. Depending 
on the current node a number of different selections are 
available. The possible selections a user can make du^'in^ an 
editing session are described in the following sections, 

1 . "s" Selection 



If "s” is selected and the current node is a nonter- 
minal, the node is replaced by the production rule identi- 
fied by that nonterminal. In the above example, if <spec_id> 
is selected, then the rule for <spec_id> 



inserted into 



the atstrdct specification tree, the screen j.s a 
the selector is advanced. 
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SPEC <spec iu> IS 
<spec_'Eiock> 



{< para m_biock >) ? 
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^spec rdJ ! 
SELECTIONS:" I 
s:select diselector down u:selector up edit 1 
b:selector up tree f: selector down tree' j 



SPEC <identifier> IS 
<param block> 

< spec_Elock> 
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TIOTJE: ^iaent^ifier'? | 

SELECTIONS: j 

s; select d: select or down u: selector up ecin i 

b:selector up tree f:selector down tree 



Figure 4.2 Selection of a Non-ter ainal. 

If the current node is an option node, then the ”s” 
selection will inhibit the display of the question raark am 
the nontermina Is/terminals proceeding the modifier will 
become part of the abstract specification tree. A sinilar 
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rtisalt occurs when the current node is a selection nodi tier. 
In this case, all selections which are no longer needed 
along with the selection symbols are not displayed when the 
desired selection is made. 

Figure 4.2 shows the tree before and after an update 
where <spec_id> and <param_block> were selected. 

2. "i" se lection 

The ’’i" or insert selection is available only wh-;n 
the current node is an identifier nonterminal desijnated n/ 
<identif ier >. l/hen this selection is made, the porticn. of 
the screen where the identifier occupied is blanled. The 
user at this point can then type in the identifier desired. 
The input characters are then checked to ensure correct 
lexical grammar for identifiers- If the input cnaracter is 



incorrect. 
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the screen respectively. 

Some nodes the sel_ptr stops on are not displayahie. 
In these cases, all the descendants in the tree that are 
eligible are displayed via the selector. As an example, if 
<module_spec> is the current node then all of the displayei 
characters in figure 4.2 would be inverted and < .'noduie_spcc'' 
would be displayed at the bottom of the screen after 
"NODE : ". 
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4. ”u” and "d" Solec tions 



The ”u" and "d" selections are sinildi to tht ’’o" 
and "f" selections; they move the selector up and down the 
screen. The difference is that the "u" and ’’d" selections 
will move to the next displayable node on the screen. This 
facilitates moving the selector on the screen. 

5. ’'ffi" Selection 



The ”m" selection is used when the current node a 
selection modifier node. Since the "f”/ "1", '’u'' and "d-'' 

selector movement selections will not allow moving tlie 
selector into a modifier node subtree, tne " m*' or "naxe 
selection" hey was created sc the user could rove the 
selector over the desired selection. If the selector is on 
the last selection and "m" is selected, then the selector 
will move back to the first selection. Tlie selector will 
remain in the selection tree until either a solecrion is 
made or the user makes a "j" selection to jump out of the 
selection. 



6 . "e" Se le ct ion 

The "e" selection allows the user to "erase" the 
string the selector is on. This means that tne string will 
no longer be displayed on the screen. The "e" selection is 
available when the current node is the option node or u 
nondisplayed nonterminal. 

If the selector has an option symbol in its field, 
the erase selection will eliminate the option symbol, 
brackets if displayed, and the nonterminals and modifiers in 
the selectors field. In figure 4.2 if ara.‘n_i;iock> was not 
desired and the selector was positioned on (<pdr am_block> ) ? , 
then the erase selection would yield the following display; 



SPEC <identifier> IS 
<spec_body > 



46 



T'aen the nodt indicdted at the bott:c 2 df t ue ’ie.lay 
is not a dispiayabie node, the erase wiii eiijiii.ate all of 
the strings of the screen which are in selector's field and 
replace them with that node. 

7. "r” Selection 

The ”r” selection is used to replace an option node 
in the display or a selection node. In the previous example 
for erase, if the sel_ptr was positioned in the specifica- 
tion tree so that the option may be reselected, then the ''r” 
selection would replace the option tree in the specification 
tree and the display would Le updated accordingly, A 
selector would not be visible in the case where the option 
was previously erased. The replace field at the bottom of 
the screen would indicate the option to be inserted into tn e 
tree . 

In the case that the option or selection nas been 
previously made, then the entire portion of the tr<=e fro.a 
the option or selection would be eliminated. The strings 
that would be eliminated are in the selector’s field. 7cr 
example, if the specification was as follows: 

SPEC <identifier> IS 
PAEAWETESS 

<spec_i 3 iock> 

DEFINED 3Y 

<spec_biock > 

and the current node was the "not” diSj^layed option node 
<para m_block>? , then a "r" selection would yield: 

SPEC <identifier> IS ( <param_bi ock>) ? 

<spec_block> 



B. DESIGN OF SPECED 



The editor was written in Pascal and implemented on a 
Digital Vax 11/780 under the VMS operating system. The 
editing session described in the preceeding section was the 
objective before the design of the editor started. 

The design of the program was done in a top-down manner. 
The three primary modules are as follows: 

1. Initj-alization 

2. Main body loop 

3. Termination routine 



^ be^gn Decisi ons 



by the editor, 
carriage return 

before a nontor- 



In order to simplify the display, certain nontermi- 
nals are treated in a special manner. The <indent> and <cr> 
nonterminals are immediately interpreted 
These nonterminals mean indent and 
respectively. 

The indent nonterminal, <indent>, 
minal or expression means that the nonterminal and its 
descendants will be indented by a preset tab or spaces if a 
carriage return follows. 

The identifier nonterminal, <ilen tif ier> , is treated 
as a slot for inputting a string of characters. This seems 
reasonable since all grammars reguire idenr.ri i ers . The 

lexical composition of the identifier is L ui Ir into th-j 
editor. 



2 • -initiali za tion 



The first routine called by 
Initialization. This routine in turn 
opengrammar to input the production 
file. Opengrammar has a scanner that 
rules to ensure that lexically they a 



the main program is 
calls a routine called 
rules from a graLiiuar 
pr eirocess es tho input 
re correct. II "looKs'’ 
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for a hracAeted left hand side cf eaci. rile , n. 
tlier* bracketed string's, quoted strings ana n;etasyr iiols. die 
grammar rules are put into a record structure which consists 
of a left hand side and a right hand sice of the production 
rules . 

The next procedure called is par segrammar . T iii s 
routine is a recursive descent parser. The parser is based 
on d LL ( 1) grammar grammar used to construct tiiO ^i.uuucrion 
rules. The grammar grammar for the parser is as foj.lovs: 

<production_r ule> -> <iioiiterminal><r uis_r ody> 

<rule_body> -> ( (<n onterminai> j< ex pression>) ’ j ^ ) 

<expression> ->' ( <rule_body> l<ident_list>) ’ ) ’ 

<ident_list> -> <nonterminal> (M ' <rion ter minal> ) + 

Each production rule in the grammar grammar is 
mimicked by a module in the recursive descent parser. Every 
production rule in the grammar for Speclang is parsed into a 
separate production rule tree which describes its syncactxc 
structure. 

figure 4.3 shows an abstract production rule tree 
for the <module_ spec> production rule. 

For each production rule tree there is pointer i;. an 
array of pointers to locate that rule tree. Ihe rule trees 
are located by searching the array for the root wiMi e name 
that marches. A production rule tree is construe ted from 
records which have pointer and integer fields ns follovsi 
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raminruly s = recorl 

parent ; array ( 1 .. 2 0) of character; 
ien:integer; 

child : ar ray ( 1 .. 30 ) of 1 gr ammr ales; 

par_ptr: j graramruies ; 

ch_no : i n teger ; 

rty pe : in te ger ; 

num_ch : i nteg er ; 

disp : boo lean ; 

In: integer; 
end 
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1 

<nodule_spec> -> *SPEC* <spec id> ’IS’ 1 

(<indent^<cr><parac'._Llock>) ? i 

<!ind€nt><cr><spec_hody> | 



I 

i 

< module spec> | 

! 



SPEC <spec_id> <cr> ? <indent> <cr> <s pcc_boa yp j 

I 

i 

^ 1 

EXP 1 

I 

I 

? 

I 

<cr><indent><parm block> j 

I 

i 

I 





Figure 4.3 A Production Rule Tree. 

The ’’parent" identifies the name of rule, string, or 
modifier. The field after parent, "len", contains the 
length of the parent character string. This feild is used 



c n 

U KJ 



cl r L d \ 



ir. outputti::y the strin^ on tht screen. The "chiia" 
points to the descenaants of that rule. A pcintei cali.C:l 
"par_ptr" points to the parent of that node. This pointer 
was necessary in order to move tne selection pointer around 
the abstract tree. The '■'ch_no'* field identifies what child 
number that record node is of a parent record node whereas 
the num_ch field indicates the lumber of children that nodes 
has. The ch_no and nua_ch fields were also created to 
facilitate selector acvement. The ”ln" riel; is used for 
the display screen. field tags the "ty^-e" of record node. 
There are seven types of nodes as shown in Table I . 



1 

2 

3 

4 
4 
6 
7 



TABLE I 
Node Types 

^sscription 
nonterr.i nals 
modifiers-?,-, ,+ 
terminal strings 
expression node 
identifier strings 
ALT node 
ignore node 
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The node ty has an effect on the selections available, how 
the tree is "unparsed" for display, and the movement of the 
selection pointer. 

After the rules are parsed a procedure, get_tree, 
will open the file of a specif icat ion tree that was stored 
after a previous editing session, if the user inputs the 
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r.aaio of the file. If a user stored tree is not su;.plied^ 
the ihitializat ion routli.e will copy the first pr od uct i.0.1 
rule tree ai.d use it as the root of the specif icatior. tree. 

Ihe final steps of the initialization routine set up 
the display for an editing session. A pointer, prog_ptr. 
will be set to point at the root node. If a user specifi«sl 
tree is available then the prog_ptr is sot to the root of 
that specification tree. 





•j.he 


no 


xt 




st e 


p is 


to 


c 


2sar 




t 


no 


s 


creen 


and 


d 


il 




rout 


iiie, J 


rin 




ti 


ee. 


vhi 


ch " 


u 


npar 


50 


3 


it 


t 


ne tr 


ee to 


or 


oa 


uco 


the 


display 


on 


t 


he 


i 3 C 


reen. 




























"he 




na 


1 


step of 


the 


i 


nit i 


al 


i 


za 


ti 


on ro 


uti ne 


as 


si 




the 


selection 


P 


oi 


.nt.e 


r to 


the 




firs 


t 


s 


el 


ec 


tion 


of t h 


e 


tr 


ee • 


If t 


he ini 


tia 


1 




•od uction 


r ul 


e 


wa 


s 


A 


is 




ayed 


t li e a 


is 


tr 


ac t 


tree 


would 


app 


ea 


r 


as 


follows : 




































<comp 


_spec 


> 





















> 1 ' 

<sel_ptr> > + 

EXP 

/ 

<ind€;n tXcrX mod u le_spec> 
a. Print Routine 

The print routine, which unparses the specifica- 
tion tree being developed and displays it on the screen, 
deserves further explanation due to its complexity. It is a 
recursive procedure which does an inorder- traversal of the 
specification tree and, as it visits each node, will respond 
according to that node’s type. 
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Initiaily, the iroj_ytr is ..assed zo tne llii:! 
routiiie and then a case ^atateaent determines how to handle 
the root noue and ail nodes recursively passed to it. Since 
the root node is the left hand side of the first production, 
it is not displayed. Instead, it treated as a nondis pla yen 
nonterminal node v/hich is explained below. 

The predcminar t factor as to vhethei or not a 
node parent's neld is to be disprayeu rs ti.e re^.^ord booleai. 
field "cisp". Only if the field is true will it bo output to 
the screen. 



aiiOther factor for displayali li ty is the line 
number of the nodo. Since the screen car. only dispicry a 
small fixed number of lines cf the spociiica tion at one 
time , a current line is assigned for t]ie display which will 
dictate what nodes in the specification will be snown. If a 
node’s "In” field is in a particular value range of the 
dis£'lay line number then it will be displayed. Ot;u-rA/ise, 
even if the disp field is true, it will not be displayed. 
For example, if the current line is twenty, then all the 
sped f ication nodes whose In field falls in the range twenty 
to thirty five will be displayed. 

As mentioned before, the print routine responds 
to a node's type via a case statement which has seven cases 
tnat correspond to the seven node types in Table I. 

Case one handles nonterminals. This case chechs 
initially to see if the nonterminal is a carriage ceturr. <^r 
an indent. If it is a carriage return, the screen line 
number is incremented and the selector positioned on the 
next line of the screen. If the nonterminal 
symbol, a global indent counter is ' increment ed 
indent flag is set. This mechanism is usoa to cause uhe 
nonterminal and its descendants following the indentation to 
be indented. 
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Before a Dont ern i ral or its des'ji-jr.dai'ts are 
displayed on the screen, a glotal flay is checked ro se^i if 
the preceding nonterminal was an indentation. If it was, 
then the global flag is set to off and a local flag is 
turned on. After the nonterminal or its descendants are 
displayed, the local flay is checked. If the flay is on, the 
number of immediately preceeding indentations are subtracted 
from an indentation counter and the local flag is turned 
off. Using this method, the indentation affects only the 
nonterminal or the expression fcllowin^ it. For example, if 
the rule for <module_£pec> was: 

<moduie_spec> -> SPEC <spec_id> IS 

(<ind en tXcrX par am_b io ck> ) ? 
<ind€ntXcrXspec_block> 

The initial display would be as follows: 

SPEC <spec_id> IS (<param_block>) ? 
<spec_block> 

When <param_block> is expanded the indentation will affeci; 
all of its descendants so that the display would appear as 
follows: 

SPEC <spec_id> IS 
PAHAMEIEHS 

<sp €C_block> 

DEFINED 3Y 

<sp€c_block> 

Note that <spec_block> is inderted by two. This happened 
because the rule for <param_block> has an <indent> at the 
end and the rule for <module_spec> nas an <in denO 
preceeding it. If <param_blcck> was eliminated, then 
<spec_block> would only be indented by one. 
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carriage return or iiident, ti er, the boolean field "dis." in 
tested for displayarility. If the field is true then the 
node’s parent field is written to the screen. If the nonter- 
minal is not to be displayed, then a recursive call is made 
to the print routine for each of tlie pointers in tne "child" 
field of that node. 

Case two handles all the modifier nodes. If a 
selection modifier node is encountered and is to r,e 

displayed, the print routine will display all the selec' 
tions ana place the "i" symbol between the choicen. All the 

other modifier nodes will have a recursive call to tne prinr 

routine on their descendants. After returning from the 
recursive call, the node is checked to see if it is to be 
displayed. This is how the postfixing of the modifier 

symbols is accomplished. 

Case three handles the template nodes. These arc' 
nodes that have strings that are reguired in the grammar. 
For example, every module must have the string "SPIC" and 
tne string "IS" on the first line. These nodes have no 
descendants and so the print routine will not make any 
recursive calls on the descenda rts. 

$ 

Case four deals with expression nodes.^ An 
expression node is used to point to the descendants;' its 
only function is to allow the print routine ta ma,'.e r-:C i;r- 
sive calls on each descendant. If a global flag is set in 
the case two condition indicating the expression is followed 
by a modifier, tnen brackets surrounding the expression will 
be displayed. 

Case five prints the identifier nodes. These are 
terminal strings for identifiers and are treated like tao 
case three nodes. 

Case six deals with the "ALT" nodes. This node 
is used to store trees such as options and selections after 






thest nodes have re«;ri acted on. It also retains the Kleene 
and alternation trees. Noraally the ALT node has tvo descen- 
dant nodes. The left one is for the branch leading to 
displayed strings. The right one is for storing tne option, 
selection, Kieene and alternation trees or it ray point to 
another ALT node. The print routine will recursively call 
each of the children nodes. 

Case seven is the ignore case. This is used when 
the node and its descendants are to be ignored. For exasulc;, 
in the case where the option node was used and stored. The 
option expression is no longer desired for display so it is 
given a type seven. 

^ • Ma in Sod y Lo^L 

The editor, after initialization, enters a loop in 
the main program body which inspects the type node at which 
the selection pointer is pointing and calls one of eight 
routines to handle that case. The routines are shown in 
Table II . 

All of the routines which handle the various node 
types are essentially constructed the same. A procedure, 

sho_slection, is called in each routine which displays the 
various selections available in taat routine the bottom 

of the screen. Zach routine then enters *a loop i^liicii 

retrieves the input from the terminal and deciphers th<-- 
input via a case statement. If an invalid character is 
selected, it is ignored and the routine loops for another 
input . 

The following sections will discuss the routines in 
Table II with the exception cf the first section w-iich 
discusses the selector movement routines. 
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TABLE II 

Routines called by Main Body Loop 



I 



Node Iy£§ 

Nonterminal 

7 

1 

+ 

ident if ier 
ALT 



1 

! 

I 

I 

i 

Id_replace j 

1 

Option I 

Selection | 

j 

Alternation j 

Kleene | 

I 

Id_deselect ] 

altrep ; 



a. Selector Movement Routines 

There are four routines used to position tiie 
selection pointer on a node in the specif ication tree in 
concert v/ith the selector on the screen. They each corre- 
spond to one of the four selections, "u”, "d”, and 

available in all the routines shown in Table II . I’nen ’’i’’ 
or ”u” inputs are received, one of two routines will be 
called to move selection pointer and the selector to the 
next di spl a ya ble selection either down or up tus scne^n; 
this means the selection pointer will be at a node tnac is 
visible on the display. 

The ”b" or ”f" inputs move the selector backward 
or forward to any node in the specif ication tree that is 
available for modification. These two inputs also have two 
separate routines which move the selection pointer in the 
tree. The "b" and "f” selections allow the incerior noles, 
which are not displayed on the screen, to be available for 
alter ation. 
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All of the selector .Qoveaent L'outi;.r'. ire 
designed so that they will not i^ositrcn the se^eciior. 
pointer on "EXP” nodes# modifier nodes , if they have been 
erased or selected. and terminal type three nodes that 
contain strings used in the gracmar. Ihe nondisplayed modi- 
fier nodes are accessed in a different manner. After the 
selection pointer is moved# the current node is checked to 
determine if it is on the screen. If it is not# the current 
screen display line is updated to ^^osition that node in the 
center line of the screen. The print routine is then called 
to update the screen. 

L. Replace Routine 



The replace routine acts on type one 
nodes. Two general cases are possible# dependin 
the node is displayed. In the case where the no 
displayed# the replace routine enables the use 
the specif icati on tree the production rule tree 
the nonterminal node’s parent field. As menti 
previous section# this occurs when an "s" is in 
4.4 shows the specification tree before and aft 
input and the selection pointer is at <spe 
specif ication tree. 

Hhen "s" is selected# a routine 
locates and reproduces the the production ru 
<spec_id> and returns a pointer to the replace r 
replace routine then attaches the rule tree to 
cation tree. The <spec_id> "disp" field is then 
to inhibit its display. 

It is possible that the selection p 
a type one node that is not displayed; its disp 
to false. In this case# the displayable des 
shown in the selector’s field. An option to e 
available to eliminate all the descendants and 
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1 



<moQulc_sfec> 




<indent> <cr> <param_block.> 




<identif ier> 



4 ' 

:xp 



<indent> <cr> <pdcam_block> 



Figure 4.4 Selection of <spec_id>, 

) 

not displayed no nter ifiiial. This is acconi piish =..] by seLtaa-- 
the current node’s child pointer to ml and thi_ disp li«=l.l 
to true. The ’’NODE” field at the bottom of the scr=:£r; mows 
the not displayed nonterminal. 

One special case is addressed in tiiis roaiine. 
This is the case when the selection pointer at tne r;ovDt 

of the Si ecif ica ti on tree. In this case, the first produc- 
tion rule tree is duplicated and substituted when the ”e” 
selection is made. This is paramount to erasing the entire 
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tree . 



user 



C. IC_L'epiaCe 

The id_replace routine was created co allow the 
to input directly on the screen the identifier nacts. 
This routine is called when the selection node type is one 
and the nonterminal is <iden tif ier> . ^hen an "i" is input# a 
case statement is executed which determines the startino 
position on the screen by inspecting the current node’s 
posit field. A blank is written to the screen startinu at 
that position. The routine then cakes inputs from tne 
terminal and places them in that node’s pareuL field, Jac-i 
character input is checked for proper lexical jramDiar and is 
echoed to the screen. Invalid characters are ignored. The 
inputs are terminated when either twenty characters have 
been input or a "S" is input. 

d. Option Routine 

The option routine is called when the current 
node is type two and the parent field is the option node 
modifier. This routine will allow the user either to erase 
the optional expression by selecting an ”e" or include- the 
expression preceding the modifier by selecting an *'s". 

• When the option is selected or erased an 'ViLI*' 

node is inserted into the option node’s position in the 
tree. The ALT node is treated as if it only has two chil- 
dren. The right child will store the option tree so taat if 
the user later desires to reverse his previous decision and 
include it# he can reinsert the option tree into its prior 
position in the tree. The left child of the ALT node will he 
nil if the option is erased or will contain the expression 
that was preceding the option modifier if the option was 
selected. Figure 4.5 shows the tree before and after the 
selection of the <param_block> option. 
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Figure 4.5 Selection of the Option < parani_block>. 

When the option is stored in the rijhl chile, li 
is assigned a type eeven so that the print routine rili 
ignore it and its descendants. 

e. Selection Routine 

The selection routine is called when the selec- 
tion node is type two and the parent field is the selection 
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fflodifier. Because the selector down or selector routine 
can not access the descendants cr a selection node or o;Licr. 
node, the selection routine was written to perait the user 
to designate the desired string by using the "w" key to 
position the selector over it. When "m” is input a case 
statement is executed which will loop between the selections 
until either a selection is made or a '’j" is entered to jumj. 
out of the loop. When a particular nonterminal is selected 
the routine behaves like the option selection; an ALI node 
is inserted for the selection node and the selection node 
and its descendants are stored in the right child of iht: ALB 
node. 



f. Alternation Routine 

The alternation routine is called vht;n the 
selection pointer is at a type two node and the parent is 
the alternation modifier. The routine allows the user to 
duplicate the expression or nonterminal preceding the mcci- 
fier. When the ” s" selection is made an ALT node is 
inserted into the tree at the alternation position. The left 
child points to a cloned expression of the descendants of 
the alternation modifier and the right child points to rhe 
original alternation node and descendants. Figure 4.6 shews 
the tree before and after a selection. Unlike the option 

and selection routines, the right child in tixis case will 
not he typed seven since we want to allow the user to make 
as many selections as he would desire. After the user has 
made at least one selection, then the node can be erased; 
the alternation routine is written so that at le«-ist one 
selection of the nonterminal or selection must he made. 
This is accomplished by checking if the alternation moa.iiier 
is a child of an ALT node. If alternation modifier is, then 
a selection must have been made and therefore the alterna- 
tion tree is eligible to be' erased from the display. When 
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ar. "e" is input, the routine will chan^' 
node’s first descendant to type seven and 
false . 



t - / c. ^ , o w -•« C > 

i.e d-. s'p Tieiu. t'O 




<indent> <cr> <a::ioE_x)cdy ;> ] 
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<axioms> 




<indent><cr><axiom_body> EX? 




<indent> <cr> <d>:i or:;_i:ody> 



Figure 4,6 Selection of an Alternation Expression. 



g. Kleene Routine 

The kleene routine is executed if the cujTrnt 
node is type two and the parent field is the kleene iriodi- 
fier. Like the alternation routine, it allo\*s unlinited 
duplication of the descendants cf the modifier. The routine 
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is th€ thfe same as the alternation routine exce^-t that it 
allows the user to erase the kleene modifier ar.n its descen- 
dants even if a selection has net been made. lo accomplish 
this# the kleene node’s display field is set to false and 
the first descendant is set to type seven. 

h. Altrep routine 

The altrep routine is called when the title ct ion 
pointer is on an ALT node. As discussed before, the ALT node 
is used to handle cases for the option, selection, alterna- 
tion, and kleene routines. Conse«^uen tly tiie altrep routine 
handles two cases; one case is when the ALT node is the 
result of action taken on an option or selection node ana 
the other case is when the ALT node is the result of action 
taken on an alternation or kleere node. 

If the AIT node was the result of action taken 
on an option or selection node tnen the case statement wilJ. 
permit the user to erase the left tree, eiiminare the ALT 
node and place the option or selection tree in the specifi- 
cation tree in its former position. Figure U.7 shows the 
result of reselecting the <param_block> option which pats 
the <param_block> option tree in its previous position. 

The case where the ALT node was th e result oi 
action on an alternation or kleene node has two subcases. 
Cue case is where the ALT node proceeds another ALT node 
such as follows: 

sel_ptr ■> ALT 




<£ort_id> ALT 

<sort_id> + 

<sort id> 
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<mo-iul«_£ fec> 



SPEC <spec_ia> 




<inden tXcrXpar ara_l;lock> nXF 




<inderit> <cr> <parar _bloch> 



<inodul€_spec> 





SPEC <spec_id> IS ? <indent> <cr> 

I 

EX? 




<indent> <cr> <par am_blocK > 



Figure 4.7 Reselecting the <param_block> Option, 

In this instance, a selection is available to eliminate xh.e 
ALT node, its left child and all of the left chiiu^s aesc^rn- 
dants. In this way the user may eliminate selacticrs r.ade- 
before. 

The other possibility is where the ALT nod^^ is 
adjacent to a kleene or alternation node as follows; 
sel_ptr > ALT 




<sort id> f 




<sort id> 



t ne selection 
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In this case, tne selection to eliminate the AL"' 
able and if the kleene or alternation node has been erased, 
a replace selection is available to redisplay the kleene oi 
alternation node ana its descendants. Tiiis is done by 
setting the alternation or Kleene node’s first descendant 
type field to seven and the dis^. field to true. 



4. Termination 



After the user inputs a "g” to guit the editing 
session, the editor exits the main body loop anii then calls 
a termination routine. This routine may call two different 
routines depending on the users desires; 

1. Store Tree 

2. Pretty Print 

a. Store Tree 



This recursive routine performs an inorder trav- 
ersal of the specif ication tree to store the fields of each 
node. It is called if the user answers yes to a prompt 
asking if he wants to store the abstract tree. When the 
routine is entered, a file is opened with the filename input 
at the beginning of the editing session. Each node of the 
abstract specification tree is then visited and its fields 
stored in the file. 



b. Pretty Print 

This routine is called when the user answers yes 
to a prompt asking if he desires a pretty print rij.e of the 
abstract tree. This file will be an unparsed version of the 
abstract specification tree. It is essentially the same 
routine used for unparsing and displaying the tree on ih^ 
screen, except this routine ignores the lire naif.bcr used ror 
display. 
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V. SOMMAHY 



Speclar*j is a language based on aijebras which nas thc 
facilities lor creating formal specifications that fit tne 
criteria established by Liskov and Ziiles. Speclanj reduces 
the complexity of a specif icati cn, and makes a specification 
more readable and easier to construct b) using a mccular 
hierarchy; module specif icati cns are bui^-t ; i crt_n 
otner specif ication modules through the extend modifier. 
Parameterized specifications modules help to !i;ina.niizc .i 
specif ication by eliminating redundant specification 
modules. Futhermore, indentations and cariiege retime 
imbedded in the grammar help to promote a consistent lormat 
between specifications. A consistent format will assist, 
readers of the specifications developed from the Speclar.g 
grammar. 

Because there are many unresolved issues in using alge- 
bras for specifications which may effect the format and 
grammar of Speclang, a table driven syntax directed editor, 
Speced, was created to assist the specifier. Its purpose is 
to create syntactically correct specifications. Furthermore, 
the design of the editor permits the user to easily modify 
the grammar. 
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APPEN^n A 

SPECLANG GRAMMAR 



The production rules are written in a modiried 
BacXus-aaur (BNF) notation. An explanation of the r, eta- 
symbols used to produce terminal strings in the grarmar aie 
as follows: 

< > - A name enclosed by pointed brackets indicates a non- 
terminal in the grammar. 

’ ’ - Strings in guotes indicate terminal strings. 

( ) - Rounded brackets indicate the scope of a mcdifrer 
symbol. 

^ - The Kleene closure modifier may follow either rounded 
brackets/ terminals or non-terminals. It means that zero or 
more of the expressions/ terminals or non-terminals may be 
produced. 

+ - The alternation modifier is used like the Xlv^ene modi- 
fier. It means that one or more expressions, terminals or 
non- ter minals may be produced. 

1 - The selection modifier indicates a cnoice of non- 
terminals, terminals or expressions. It is used between two 
or more choices- In order to clarify the selection, rounded 
brackets must enclose the selection. 



? - The option modifier indicates that the 
terminal/ or expression is optional and can 



terminal, non- 
be excluded. 



-> - The production symbol indicates what a non- terminal can 
prod uce . 
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A production rule consists cf a non- ter Jiinai followed ny 
a production symbol followed by an expression. A? ex 2 rs-'^sicr 
is coait.rised of terminals, non- terminals, modifying symbols, 
and may include other expressions. 

The grammar for Speclang includes indentation and 
carriage returns to force a formatting of the specif ication. 

A specification is complete when ail the strings in the 
specification are terminal strings. This is accomplished by 
starting with a nonterminal and substituting tlie noi.ternii.a 1 
which are on the right hand side of the production rule for 
it. The remaining nonterminals are then substitute! until 
all strings are terminal strings. For example, staitir.j 
with the nonterminal <spec_module> and substituting the 
right hand part of the rule results in the following; 

<32>ec_head er> <par am_ block>? <spec_body> 

The rule for a specification header is: 

<spec_header> -> ’SPIC' <spec_id> ’IS' <new_line> <indeiit> 

It right hand side is substituted into tl*e above string to 
produce ; 

'SPEC' <spec_id> 'IS' <new_line> <indent> <par air_ block> f 

<spec_bcdy> 

<newline> ana <indent> are inter^^reted as cariiaje return 
and a tab respectively, except wnen they are in an ex^ees- 
sion followed by a modifier, and make the developing specif- 
cation appear as: 

SPEC <spec_id> IS 

<parair._block>? <spec_block> 

Since <par am_block> is optional it can be eliminated to 
produce: 

SPEC <spec_id> IS 
69 



<sp ec_ hotly > 



The suLs titut ions are continued until all strin-js ur o 
terminal strings. The first nonterminal string in Speclang 
is <comp_spec>. This denotes a complete specification. is 
mentioned in the previous section a specif icatio.i develo^^cid 
froji Speclang is made up of modules. Each module in ixself 
is a specification. To reflect this the riglit hand side of 
the production rule for <comp_spec> is <moduie_spec>+. In 
other wordS/ a complete specification is made ip of one o; 
more specification modules. 

The production rules are as follows: 

<complete_spec> -> {<module_spec><newlineXne wiino) 

<ffi odule_spec> -> <spec_header> 

(<indent ><n ewlineX par am_block>) ? 
<iiidentXn ew line><spec_blosk> 

<spec_header> -> ’SPEC’ <spec_id> ’IS’ 

<par ani_block> -> ’PARAhETEES’ <indentXnewline> 

<sp ec_ hloc k> 

’LEFINED_3y' <indent> 

<spec_id> -> <identifier> 

<spec_biock> -> ( <extend_f or m> <in.ient> <nGwiine>j ? 

( <Si>e c_.bo dy > 1 < r am _c a 1 1 > ) 

<spec_body> -> <sort_body> <rewiine> 

<op_body> <;iewline> 

< axiom bodv>? 

<ext end_f orm> -> ’EXTEND’ <newiine> 

<indent> <ex tend_iist> 

* WITH * <inde rt> 

< extend_list> -> ( (<spec_id> l<param_call>j ’ ; ’ <nevline>) ^ 
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< . aran’._call> -> <si;ec_id> ’ (’ <spec_ic> 

<indent> <newli..ir;> 

<actuai_^araLO 

<act ual_parara> -> <actual_sorts> <newiine> <actual_ops> 



< actual_sorts > -> * ACTUAL_SO RTS’ 

{<newiine><irident><£ort_id>' IS ’ <sor-!:_i I> ’ ; + 

<actual_ops> -> ’ACTUAL_OPS* 

(<iiewliiie><indent><op_id> ’ IS ’ <op_id>’ ;’) + 

<sort_body> -> ’SORT’ <newiine> 

<indein:> ( < sort _id> ' ; ’ ) + 



<aort id> -> <identifier> 



<op_iJody> -> 



’OPERATIONS’ <n€wlir*e> 



<indent > 
(<indent> 
( <iadent > 
(<indent> 



<primitive_ops> <newii:ie> 
< d eri ved_op.s> <n3wiine>) ? 
<error_ops> <newiine>)? 
<hidden_ops> <newiine>) ? 



<primitive_ops> -> ’ PF.iril j. T Vr’ <newiine> 

<iiident> <operatiOiis> 

<der ived_ops> -> ’DERIVED’ <newiine> <indaat> 

<oper a ti ons> 



<T. rror_opG> -> ’ERr.Ou’ CiuV: t> <opora 

“n ii juid<ar» op3-^ ’Hj-DDEii’ 'Cac: wr rii 

<opo ration s > 






'oporationG> -> (<op_foria> 



,ino>) 



<op_:oriu> -> 









o O 



f __ 



> 



'x o O u J, 



<sort_list> -> (<3ort_id> ( ’ , ’ <sort _id> ) *) ? 

<axicrn_body > -> ’AXIOM’ <indent> (<iiewiine> <dxion:s>} + 
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<cixiofiis> -> < «xpr ttSSion> ’=• < expressio n> 

<expression> -> (<sort,_id> J < cp_exp>) 

<op_exp> -> <op_id> (' (* <exfression> 

( * , ’ <expression>) * ' ) ' ) 



lexical grammdr 

<spectext> -> (<d elimeter>+) ? 1 (< deliEe ter_pair> >) ? 

<delimeter> -> <cocunent> | ’ ’ 1 j ’ (' ] 1 

' 1 I ’ 

<non_delimete r> -> <ident ili€r> 1 <string_constant> 
<identifier> -> <letter> (<l€t ter> 1 <digit > | 

<str ing_const an t> -> <syiii)ol>* 

<letter> -> ’ A* 1 ’ 3*1 ’C ’ 1 ’ J ’EM ’ F’ I’G ’ 1 ’ H' j ’ I ’ 1’ J ' 1 

* K* I *1* 1 *1^1* I * N* 1 *0* 1 ’ P’ 1 ' 2’ I *3’ 1 ’ 3’ j’ T’ i 

f U» 1 » V M ’ k- ’ 1 ' X * 1 ’ Y ’ I ’ Z ’ I ' a ’ I ’ b ' ! ’ c ’ 1 * d M 

*e*|*i*i *g*l*h’l ’i’i’j’i'k* i ’I'l'E’l’nM 

*o*l*p*l*q*|'r*l’s’l’t’l’a’l’v’|'wM’xM 

» y » j f 2 * 

<digit> -> * 0 * j * 1 * 1 * 2* i ' 3M ’ 4’ 1 ’5 ’ 1 ’ 6 ’ 1 ' 7’ i ' 3 M ’ 5 ’ 
<n6wiine> -> (<comirient> 1 <car riage_re turn>) + 

<comment> -> (* ! * (<symbol>l <letter>) + <carriage_return>) + 

<symbol> -> <letter> J <digit> | * j ’ | ’ a) ’ j ’ # ’ j • $' j ’ M 

« * 1 *3 * 1 * *’ 1 * ( ’ 1 M ’ 1 ' - ' 1 1 ’ + ’ 1 

« I « 1 » !»1 1 » ^ » 1 1 1 I 1 1 J =1 1 I » j • / ' 1 

’.’I’ /’I V I * {*1 *°’l ’<’1 ’>’ 1’ I 

I . I 

<indent> -> (* *+ J <tab>) 
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